home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / activeX_file_system_object.txt < prev    next >
Encoding:
Internet Message Format  |  1999-03-24  |  4.7 KB
  1. Date: Thu, 11 Feb 1999 17:37:18 -0500
  2. From: Gary Geisbert <gary@NEWSLETTERS.COM>
  3. To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
  4. Subject: Using FSO in ASP to view just about anything
  5.  
  6.  
  7. This active server page opens the FileSystemObject and streams the contents
  8. of the file specified in the "file" parameter.  The problem with FSO is that
  9. you can go 'outside' of the "\InetPub\wwwRoot\" directory using "../".
  10.  
  11. e.g.
  12. http://www.server.foo/showfile.asp?file=../../global.asa
  13.  
  14. Another problem is that since the file is being read with a TextStream, ASP
  15. code will not be executed.  So if the file specified is an ASP file, the
  16. results will be similar to the ::$DATA exploit.
  17.  
  18. For example: If this file was placed on the server of a web hosting company
  19. who allows ASP, a malicious user could use it not only to view the source of
  20. *any* other user's ASP code, but also (with a small modification) stream
  21. data into other users' ASP files.  This would essentially overwrite whatever
  22. is currently there.
  23.  
  24.  
  25. -------[ cut here: showfile.asp ]-------
  26.  
  27. <%
  28. ' grab the file from the URL
  29. FileName = Request.QueryString("file")
  30.  
  31. ' create the filesystemobject and open the file
  32. Set fso = CreateObject("Scripting.FileSystemObject")
  33. Set ts = fso.OpenTextFile(Server.MapPath(FileName))
  34.  
  35. ' read the contents
  36. ShowTheFreakinThing = ts.ReadAll
  37.  
  38. ' display them
  39. Response.Write ShowTheFreakinThing
  40.  
  41. ' EOF
  42. %>
  43.  
  44. -------[ cut here: showfile.asp ]-------
  45.  
  46. That's about it.  Email me if you have questions.
  47.  
  48. -Gary Geisbert (gary@newsletters.com)
  49.  
  50. --------------------------------------------------------------------
  51.  
  52. Date: Thu, 11 Feb 1999 16:25:46 -0700
  53. From: Joel Maslak <jmaslak@WIND-RIVER.COM>
  54. To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
  55. Subject: Re: Using FSO in ASP to view just about anything
  56.  
  57. At 05:37 p.m. 11/02/99 -0500, you wrote:
  58. >This active server page opens the FileSystemObject and streams the contents
  59. >of the file specified in the "file" parameter.  The problem with FSO is that
  60. >you can go 'outside' of the "\InetPub\wwwRoot\" directory using "../".
  61.  
  62. Yes, this is a fairly well known bug.
  63.  
  64. Solution?  NTFS permissions.  Simply run each virtual web as a different
  65. user, and make sure that user can't view each other's virtual webs, but
  66. only it's own virtual web.  This feature is actually quite useful when you
  67. need to "break out of the mold" of traditional design.
  68.  
  69. One thing that should be noted is ANY ActiveX server can be executed by a
  70. user, by simply doing a server.CreateObject in the ASP file.  Obviously,
  71. the security ramifications of this can be quite severe.  You can open up MS
  72. Outlook, and using the mail object, send mail.  Neat feature for some
  73. people, but scarry if you look at some the other interfaces in some of your
  74. applications (think attachments!)...  Do your users really have a
  75. legitimate purpose in starting up, say, Word (never tried this, but I bet
  76. it would work).  This is a much bigger issue.  An example of this use is at:
  77.         http://www.swynk.com/friends/datema/excelface.asp
  78.  
  79. It would be nice to have a way of limiting what objects can be created by
  80. server.CreateObject (yes, I realize this is probably a big modification).
  81.  
  82. In addition to this feature, how about...
  83.  
  84. <!-- #include file="..\ANYDIR\ANYFILE.DAT" -->
  85.  
  86. You might be able to get access to any file stored on the server w/o
  87. sufficient permissions (think credit card orders).
  88.  
  89.  
  90.  
  91. Joel Maslak
  92. UPDATE -- Generate Web Traffic
  93. http://www.permission-marketing.com/
  94.  
  95. --------------------------------------------------------------------
  96.  
  97. Date: Fri, 12 Feb 1999 10:51:07 -0500
  98. From: Russ <Russ.Cooper@RC.ON.CA>
  99. To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
  100. Subject: Re: Using FSO in ASP to view just about anything
  101.  
  102. Folks,
  103.  
  104. I would appreciate it if people would send their responses to Gary
  105. (gary@newsletters.com) and I would ask Gary to summarize to the list.
  106.  
  107. I let Gary's message out not because it was a bug (and to that extent, I
  108. should have asked Joel to change his message), but because it does
  109. represent a reasonable vulnerability that could be easily overlooked.
  110.  
  111. In the meantime;
  112.  
  113. Phillip R. Paradis <paradis@exploremaine.com> said...
  114. This exploit does not work in IIS4 if you deactivate the Allow Parent
  115. Paths option in Internet Services Manager. Under the application root
  116. properties, select configuration, app options, and deselect Allow Parent
  117. Paths. This prevents MapPath from resolving anything with a .. in it.
  118.  
  119. Martin DEVERA <devik@cdi.cz> said...
  120. >It would be nice to have a way of limiting what objects can be created
  121. by
  122. >server.CreateObject (yes, I realize this is probably a big
  123. modification).
  124.  
  125. there is a way, you can set perms to a registry value
  126. HKCR\Classes\{YourID} and so disallow particular user groups to read it.
  127. It effectively disables user to create an object.
  128.  
  129. Cheers,
  130. Russ - NTBugtraq moderator
  131.  
  132.